第4章　再利用性へのアプローチ

再利用性の目標

再利用性によってもたらされる利点

適時性

保守作業の軽減

信頼性

効率性

一貫性

投資

再利用への道(Reuse Path)の原則

再利用の生産者になろうとする前に再利用の消費者になれ。

何を再利用すべきか

人材

設計と仕様

デザインパターン

ソースコード

抽象化されたモジュール

「非」技術的障害

NIH(Not Invented Here)症候群

自前で用意したがる傾向

多くは開発者が新しいツールの品質に神経質になっているだけの場合が多い

調達の経済学

大企業や政府機関で再利用可能なツールの調達を阻害する制度に起因することが多い

ソフトウェア会社とその戦略

企業が提供するソフトウェアを意図的に再利用可能でない方法で提供したくなる

しかし、再利用可能なツールを助けてくれる専門家の存在に役割がある

ツールを内部で使う場合でも特定の領域を解決する再利用可能なツールはその領域を解決できない競合他社に優勢に立てる

部品を入手する

どれだけ優秀なツールでも知られないと使われない

部品のインデックス付け

再利用可能な部品の配布形式

ソースコードは提供せずバイナリ形式が好まれるが、ソースコードの公開に賛成する意見としては非公開にしても効果は限定的であること、公開された優れたソースコードは良い技術の見本になる

評価

技術的な問題

変更と不変性

似たようなプログラムはいくつもあるが、少しずつ違うため難易度が上がる

再利用とやり直しのジレンマ

モジュール構造の5つの要件

型のバリエーション(Type Variation)

具体的な型を使うだけではなく、様々な型の要素に適用できるように総称モジュールが必要

ルーチンのグループ分け(Routine grouping)

ルーチンをpackageとして適切に分類する

実装のバリエーション(Implementation Variation)

表現の独立性(Representation Independence)

汎用的な再利用可能なモジュールは、ユーザーが実装内容を知らずに操作できなければならないこと

動的束縛によって実行時に自動的に選択させる

共通する振る舞いのふるい出し(Factoring Out Common Behaviors)

伝統的なモジュール構造

ルーチン

パッケージ

パッケージを評価する

多重定義と総称性

構文的多重定義

ルーチンの多重定義は顧客のための機能である。ある一つの概念を表す異なる実装を使うとき、顧客は一つの記述で済ませることができる。

プログラム中の名前に一つ以上の意味を付加する機能

ルーチンの多重定義（オーバーロード）は誤解しやすい

意味的多重定義

動的束縛は表現の独立性を助けるが、公明正大の原則に反する。

表明(assertion)で複数の異なる変化表明を保つルーチンの共通の意味を記述することができる。

総称性

基本的なモジュール技法を評価する